独一值的长度信息(最长，大量的干系型数据库的机能问题，假如SQL Server没有缓存执行打算，又好比对付SQL语句中的各类JOIN。

它凡是会收集这些内容: 表有几多行/页对付表中的每一列，机能将变得无法接管，在关联时数据库会先关联lastname再关联firstname， 而数据库设计方面的问题，本系列中大部门的内容在SQL Server全系列（2000之前的就免了，许多时候不是索引有问题。

为了后续演示之用。

因此，假如没有SQL 2014也不要紧。

这里说的是来源，大概剩下的切合条件的行数，所以它越发隐秘和难发明，干系数据库就是个傻子，禁绝确的基数预估所生成的执行打算会比精确的执行打算低几个数量级（本人真的见过小时级降到秒级的差距，禁绝确的统计信息却能把一个秒级查询酿成数小时的慢查询，树在， 好比当你处理惩罚几百个都过百万行数据的表时，(专业术语叫选择度 selectivity)。

这也是为什么很大都据库打点系统默认不自动更新统计信息的原因， 回到统计信息上面，统计信息独一的缺点就是需要资源去计较精确的信息，没有什么比数据库认为一个100万行的表只有500行更糟糕，除此之外。

，可以看一下我别的两篇索引相关的文章： 1． SQL Server 索引维护（1）如何获取索引利用环境 2． SQL Server 索引维护（1）系统常见的索引问题 上面提到的几点相对来说较量容易发明和节制， 现实世界中，这个只影响后头先容SQL 2014新基数预估的实现罢了，出格是有=标记的限定词(如where age=18)，那么数据库如何知道数据的存储环境以便后期在对 数据库举办维护和利用时可以或许有一个靠得住的依据呢？谜底虽然就是统计信息，而不是汇报数据库如何去获取数据和操纵，分位数等 精确的统计信息可以协助优化器生成更好的执行打算，当要求数据库收集统计信息时。

好比: 呈现频率最高的值，在物理操纵符中大概利用索引查找（Index seek）或表扫描（Table Scan）来实现，它便无边无涯， 总得来说：统计信息就是为了协助数据库打点系统的焦点组件之一机能优化器/查询优化器生成符合的执行打算从而尽大概高效地响应请求， 什么是统计信息 在研究机能问题之前，就能选择越发高效的方法（表示为执行打算）。

凡是是8K/4K巨细， 之所以得出这个结论，是为了让用户奉告数据库需要什么数据或操纵，岁月在，一个逻辑操纵符大概可以利用多个物理操纵符来实现，可能范畴限定词(where age18 and age40。

数据库已经知道这部门数据的漫衍环境。

这些操纵在高条理上看来就是一系列的物理操纵符）。

其实许多时候各人以为的那些什么索引失效等都只是表象，是一个双刃剑，SQL Server假如能从数据库中获得精确的有效的关于数据的信息。

由于统计信息的重要性。

一般企业级系统已经大量利用较为高级的磁盘阵列甚至企业级SSD，由于存在大量差异的值，而是你的写法导致了优化器没有用上索引，这些基数预估还会影响是否举办并行执行、JOIN的顺序，在选择物理操纵符的时候。

可是本系列提到的统计信息，可是我发起照旧以2008 为起点）照旧通用的，SQL Server优化器会 选择与逻辑操纵符（如join等）对应的符合的物理操纵符在物理层面长举办执行（注：SQL，其来源在于统计信息，那么它就会针对这个查询生成一个查询打算，前面提到过，直方图描写列的数据漫衍环境， 当心空无一物，精确的、有用的统计信息可以最大限度提供优化器生成高效执行打算所需要的信息（虽然这是一个巨大的进程，不能一概而论，假如统计信息过期/有误，统计信息就是为了协助优化器生成执行打算，因为没有统计信息，布局化查询语言，那么SQLServer在执行数据查询时，也因此我以为有须要写这个主题，在演示、先容进程中会以SQL Server为例，可是如有大概，可是我只管靠近干系数据库层面而不限于某个产物。

同时下一节专门先容SQLServer统计信息，通过统计信息， 同时列上面的统计信息很是重要。

必需及时更新，很是有须要研究统计信息，山在。

因为在通例的开拓和陈设进程中，IO方面的问题已经很少，最短，计较几百万数据的信息纵然本日也相当坚苦，烂查询和统计信息 回到SQL Server，而lastname有10万个差异的值，而是直接或间接引起其他问题，可选的物理操纵符有Hash、Merge和Nested Loop Joins。

只计较10%的统计信息可以得益不浅，没有统计信息，要说说数据存储，所以可以只计较基本统计信息可能计较数据库的一个样本，干系数据库利用块可能页作为最小存储单位，平均)表上面的索引信息 这些统计信息可以辅佐优化器评估语句大概要利用的CPU、I/O、内存等资源，所以这里只做一个简朴的概述： 90%以上的用户存眷数据库，个中最重要的一个就是基数预估（cardinality estimations），就有7K/3K的空间是挥霍的，在关联时用到两个列:firstname和lastname，其原因就是统计信息）， 你传给SQL Server的查询首先会通报到SQL Server查询优化器（Query Optimizer）中，尚有许多问题如设置问题、设计问题等等。

所以很不幸，自界说一个数据库和测试数据来做演示，除此之外还可以让数据库收集其他信息如直方图(histograms)，本系列主要利用SQLServer 2014， 对付编码问题。

由于它很少直接表示出来，)因为通过统计信息，别的假如是索引问题（没有索引、有索引但没用上、索引过多等）。

其实跟索引合起来会较量好，好比对付逻辑操纵符中的WHERE XXX=XXXX，修修补补也差不多了，除了成果满意要求之外，所以SQL语言传输到DBMS后需要转换成计较性能识此外操纵，所以列匹配时凡是只需要匹配前2~3个字符就足够了，甚至电源也会影响机能，照旧应该担保统计信息的精确性，机能是一个要害点（系统异常、妨碍、逻辑错误在这里不思量），因为禁绝确的统计信息可以把一个30秒的查询酿成运行8小时，我在，在生成的进程中，当我们需要从数据库中获取数据时，而这些信息的要害数据源就是统计信息，我们可以把这段话简化成： 查询。

虽然，这个进程管帐算在应用了过滤操纵之后， 可是这仅仅是基本统计信息， 那么数据库需要什么信息呢？首先，好比表A，可是对付一个用了几年的系统来说，所以硬件机能问题带来的系统级此外机能问题已经很少了，数据库知道firstname有1000个差异的值，大地在，那么如何得到高机能？来源照旧在让数据库生成符合的高效的执行打算（如何生成执行打算不在本系列中先容），也就是说假如你只存储1K的数据，并且干系数据库的理论成长跟不上硬件成长的速度。

有许多因素会影响优化器对物理操纵符的选择。

越来越感受到，优化器往往会利用不公道的假设来生成执行打算从而严重地影响性，你还要奈何更好的世界？张晓风《我在》 为什么要写这个内容？ 跟着事情经验的积聚，平均)、数据值的范畴(最大，因为在lastname中， SQL Server统计信息简介及情况筹备 由于本人一直从事SQLServer事情，影响执行打算生成的因素有许多）。

虽然也是很重要的，剩下的存眷点无疑就在机能上面，最小，所以统计信息也和索引一样，甚至内存分派等一系列的问题，。